home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16122 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.0 KB
  1. Path: news.crd.ge.com!rebecca!rpi!not-for-mail
  2. From: danm@zipnet.net (Dan Muller)
  3. Newsgroups: comp.lang.c++,comp.lang.c++.moderated,comp.object
  4. Subject: Re: C++ objects in shared memory
  5. Date: 9 Apr 1996 08:41:21 -0000
  6. Organization: ZIPNET.NET - The NorthEast US's premier ISP
  7. Sender: cppmods@netlab.cs.rpi.edu
  8. Approved: devitto@ferndown.ate.slb.com
  9. Message-ID: <4kd7rh$m2a@netlab.cs.rpi.edu>
  10. References: <4jtte3$5ng@netlab.cs.rpi.edu>
  11. NNTP-Posting-Host: netlab.cs.rpi.edu
  12. X-Original-Date: Fri, 05 Apr 1996 04:35:19 GMT
  13.  
  14. Tony Confrey <ac11@gte.com> wrote:
  15.  
  16. >I am trying to store instances of C++ objects in shared memory so 
  17. >that their function and data members can be accessed by multiple
  18. >processes running on the same unix box.
  19.  
  20. >Storing the instance in shared memory is no problem - I've been using
  21. >placement new with a previously allocated block of shared memory that
  22. >all processes connect to. Calling member functions, in particular 
  23. >virtual member functions, is more difficult.
  24.  
  25. >I'm finding (actually more like deducing) the following: If process 
  26. >A creates an instance then the vtbl points to function addresses in
  27. >process A's address space. Calling non virtual functions or 
  28. >accessing data members from another process, B, works fine. 
  29. >However calling virtual functions from B segv's because its 
  30. >trying to call outside its address space. 
  31.  
  32. >For a while it looked like linking the class library as a shared library
  33. >would work - in fact it does under aix - because the functions end up in 
  34. >the same place in memory. However under solaris the address spaces are
  35. >mapped differently.
  36.  
  37. >Any suggestion would be appreciated. Can this be done? Is there some
  38. >other approach I should take? I find it hard to believe that no 
  39. >one has ever tried such a thing.
  40.  
  41. Tony,
  42.  
  43. The approach you're trying would be really nice if it worked, but as
  44. you're finding, it's not at all portable and may not work at all on
  45. some systems.
  46.  
  47. You're probably better off using a proxy approach. In each process,
  48. create proxy objects that have the same interface as the "real"
  49. object.
  50.  
  51. The real object could exist in one process, and the proxies could
  52. communicate with it via any number of methods. This is the basic idea
  53. used with most distributed object systems, where the real object might
  54. not even be on the same machine. RPC mechanisms are commonly used to
  55. communicate between proxies and the real object, because they can
  56. handle much of the marshalling/unmarshalling work easily.
  57.  
  58. However, this might be overkill. In your case, the "real" object might
  59. just be a block of data in shared memory, and the proxies coordinate
  60. access to the data. You'll still have a problem with pointers, of
  61. course.
  62.  
  63. This is very brief, but I hope this gives you some ideas.
  64.  
  65. --
  66. Dan Muller
  67. danm@zipnet.net
  68.  
  69.  
  70.       [ Articles to moderate: mailto:c++-submit@netlab.cs.rpi.edu ]
  71.       [  Read the C++ FAQ: http://www.connobj.com/cpp/cppfaq.htm  ]
  72.       [  Moderation policy: http://www.connobj.com/cpp/guide.htm  ]
  73.       [      Comments? mailto:c++-request@netlab.cs.rpi.edu       ]
  74.